<html>
<head><meta charset="utf-8"><title>alloc non-global-oom support · t-libs · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/index.html">t-libs</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html">alloc non-global-oom support</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="235722413"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235722413" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235722413">(Apr 22 2021 at 18:05)</a>:</h4>
<p>I wanted to kick a thread off here so we can hopefully reach some conclusion (or how to go about it) for <a href="https://github.com/rust-lang/rust/pull/84266">https://github.com/rust-lang/rust/pull/84266</a></p>
<p>I think from my perspective I'm not aware of fundamental blockers, so if someone feels there should be, then I think it'd be good to figure out how to raise those concerns. (I have implementation concerns, as indicated with my review comment, but they're quality of life rather than intrinsic to the approach)</p>
<p>cc <span class="user-mention" data-user-id="220594">@John Ericson</span></p>



<a name="235722824"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235722824" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235722824">(Apr 22 2021 at 18:07)</a>:</h4>
<p>Yeah, my biggest concern is that there is going to be a pretty constant stream of things that miss the cfg</p>



<a name="235722914"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235722914" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235722914">(Apr 22 2021 at 18:08)</a>:</h4>
<p>and it may tie our hands in how we implement certain internal bits (e.g. imagine we wanted to switch from a non-allocating to allocating stable sort algorithm or something like that)</p>



<a name="235722962"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235722962" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235722962">(Apr 22 2021 at 18:08)</a>:</h4>
<p>Well, setting up CI to statically check for that is easy, I believe, but it is definitely a burden on each PR</p>



<a name="235723070"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235723070" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235723070">(Apr 22 2021 at 18:09)</a>:</h4>
<p><span class="user-mention" data-user-id="219747">@Simon Sapin</span> has a valid, I think, concern that this may be too niche for std itself; it may also be that we <em>do</em> want to support this experiment but as e.g. a alloc_fallible crate which alloc itself builds atop of. But that is definitely a significant increase in complexity.</p>



<a name="235724409"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235724409" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235724409">(Apr 22 2021 at 18:18)</a>:</h4>
<p>A downside of Rust-for-Linux forking <code>alloc</code> is potentially duplicated effort in future improvements, but it’s not obvious to me that that’s much worse than accepting all of this complexity in the standard library</p>



<a name="235725145"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235725145" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235725145">(Apr 22 2021 at 18:23)</a>:</h4>
<p>I think a key question may be if it's possible to achieve what Rust-for-Linux need without being in std (and having access to unstable features etc.) -- if there's some minimal core we need to stabilize to make an out-of-tree alloc without global OOM possible, then targeting that may make more sense then this current avenue.</p>



<a name="235725276"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235725276" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235725276">(Apr 22 2021 at 18:24)</a>:</h4>
<p>But I also am not sure about the constraints being operated in here, and that may help inform the correct approach. It may be very useful in the end to have fallible local allocators (for e.g. putting a btree inside a fixed-size arena); we may not want that in std, though.</p>



<a name="235728227"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235728227" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235728227">(Apr 22 2021 at 18:43)</a>:</h4>
<p><a href="https://github.com/Rust-for-Linux/linux/issues/2#issuecomment-821289042">https://github.com/Rust-for-Linux/linux/issues/2#issuecomment-821289042</a> discusses the lang items used by <code>alloc</code> and how to not need them</p>



<a name="235729038"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235729038" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Alex Gaynor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235729038">(Apr 22 2021 at 18:49)</a>:</h4>
<p><span aria-label="wave" class="emoji emoji-1f44b" role="img" title="wave">:wave:</span> I'm one of the folks behind for Rust-for-Linux, happy to try to answer any questions that exist.</p>



<a name="235731843"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235731843" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235731843">(Apr 22 2021 at 19:09)</a>:</h4>
<p>In the wider ecosystem adding new features that are enabled by default and are necessary to retain compatibility are actually breaking because there may be users downstream who have default-features=false set for any reason.</p>



<a name="235731980"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235731980" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235731980">(Apr 22 2021 at 19:10)</a>:</h4>
<p>But then I think std-aware or sysroot-aware cargo isn't a thing yet is it?</p>



<a name="235732115"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235732115" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235732115">(Apr 22 2021 at 19:11)</a>:</h4>
<p>-Zbuild-std isn't stable, but AFAIK is not unused</p>



<a name="235732133"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235732133" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235732133">(Apr 22 2021 at 19:12)</a>:</h4>
<p>(so seems to work OK)</p>



<a name="235732403"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235732403" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235732403">(Apr 22 2021 at 19:14)</a>:</h4>
<p>build-std is used a fair bit for embedded systems without pre-compiled libstd I think</p>



<a name="235734639"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235734639" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235734639">(Apr 22 2021 at 19:29)</a>:</h4>
<p>BTW I made an issue in <a href="https://github.com/rust-lang/wg-allocators/issues/87">https://github.com/rust-lang/wg-allocators/issues/87</a> too.</p>



<a name="235735006"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235735006" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235735006">(Apr 22 2021 at 19:32)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/pull/84266#issuecomment-825113967">https://github.com/rust-lang/rust/pull/84266#issuecomment-825113967</a> Does this mean its slated for the 28th?</p>



<a name="235735899"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235735899" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235735899">(Apr 22 2021 at 19:38)</a>:</h4>
<p>yes</p>



<a name="235735972"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235735972" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235735972">(Apr 22 2021 at 19:38)</a>:</h4>
<p>at least for Pacific Time</p>



<a name="235736098"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235736098" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jane Lusby <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235736098">(Apr 22 2021 at 19:39)</a>:</h4>
<p><time datetime="2021-04-28T19:00:00Z">2021-04-28T12:00:00-07:00</time></p>



<a name="235736407"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235736407" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235736407">(Apr 22 2021 at 19:41)</a>:</h4>
<p><span class="user-mention" data-user-id="220273">@Jane Lusby</span> thank you!</p>



<a name="235737332"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235737332" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235737332">(Apr 22 2021 at 19:48)</a>:</h4>
<p><span class="user-mention" data-user-id="130046">@Alex Gaynor</span> Do you have thoughts on Rust-for-Linux forking <code>alloc</code> v.s. working to make upstream <code>alloc</code> do everything it needs?</p>



<a name="235737416"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235737416" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235737416">(Apr 22 2021 at 19:48)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219747">Simon Sapin</span> <a href="#narrow/stream/219381-t-libs/topic/alloc.20non-global-oom.20support/near/235724409">said</a>:</p>
<blockquote>
<p>A downside of Rust-for-Linux forking <code>alloc</code> is potentially duplicated effort in future improvements, but it’s not obvious to me that that’s much worse than accepting all of this complexity in the standard library</p>
</blockquote>
<p>I responded to this in <a href="https://github.com/rust-lang/rust/pull/84266#issuecomment-825117489">https://github.com/rust-lang/rust/pull/84266#issuecomment-825117489</a>, but to expound a bit I think one of the most interesting aspects of getting Rust in major projects like Linux is to promote the idea that non-userspace projects can share code too. Right now, due to the inflexibility of C, things oftend  copied pasted once and modified, whether it's cheap android phones with non-upstreamed kernels, embedded systems with various SDK ROTC code, etc. Projects like ZFS which target multiple kernels are extremely rare.</p>
<p>Rust has done a great job of showing that sharing code even at the bottom of the stack is possible. There are currently unfortunate build system issues preventing Cargo from being used with Linux, but I hope those are addressed. Getting alloc right is the best opportunity here to do demonstrate the care that goes into Rust libraries and how they are good for far more than is originally envisioned. And that is in turn a way to begin to nudge the broader embedded community away from their "vendor and forget" practices that lead to so many issues.</p>



<a name="235737438"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235737438" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235737438">(Apr 22 2021 at 19:48)</a>:</h4>
<p>(where adding the ability to make some APIs not available is also "doing")</p>



<a name="235737669"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235737669" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Alex Gaynor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235737669">(Apr 22 2021 at 19:50)</a>:</h4>
<p>From my perspective: No panic-on-allocation-failure APIs is a hard requirement, and some of the other stuff (e.g. flags) is a nice to have, since that can easily be added on top of an existing thing.</p>
<p>I think it's really a question of timelines -- in an ideal world we'd be able to use upstream <code>alloc</code>, but if it's a substantial difference in how long it takes to get something working, it might make sense for us to fork as a short-medium term solution and then hopefully merge back to upstraem at a later point.</p>



<a name="235738229"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235738229" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235738229">(Apr 22 2021 at 19:54)</a>:</h4>
<p>Also re long term maintainability, stuff like this ought to light a fire under <a href="https://github.com/rust-lang/rfcs/pull/1868">https://github.com/rust-lang/rfcs/pull/1868</a> to make that finally get implemented. Then the pain of dealing with cfgs evaporates more or less entirely.</p>



<a name="235740201"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235740201" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235740201">(Apr 22 2021 at 20:08)</a>:</h4>
<p>I'm not sure if the lint would help. What would be needed here is to check that the compiled output contains no call to <code>handle_alloc_error</code>, even if it goes through several internal methods. The lints only check based on cfg, so would still require cfgs being applied everywhere.<br>
It would take a different kind of lint.</p>



<a name="235748987"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235748987" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235748987">(Apr 22 2021 at 21:09)</a>:</h4>
<p><span class="user-mention" data-user-id="330154">@The 8472</span> it should. The "cfg" solver can largely treat <code>os(linux)</code> <code>feature = "..."</code> as block boxes, akin to a SAT solver. (if we want to add a litttle domain-specific info like onely one OS at a time, that would be SMT.) In this case, we're just tracking down that all variables have unambiguous resolutions under all (realistic) cfg combinations, which is this sort of analysis's bread and better.</p>
<p>I don't want to get too much into the weeds off topic but I'd be happy to link you the relevant prior research if you are interested.</p>



<a name="235749734"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235749734" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235749734">(Apr 22 2021 at 21:15)</a>:</h4>
<p>I'm not sure if we're even talking about the same thing. What I am trying to say is that the lint relies on cfg <em>at all</em>. Which means you would have to slather cfgs over all the fallible or infallible methods, which <a href="https://github.com/rust-lang/rust/issues/84266">#84266</a> already does.<br>
If we wanted to be more lightweight we'd need something different, e.g. checking if the build output doesn't contain certain methods in its call tree. <br>
Then you wouldn't need to cfg thousands of methods and instead get build failures when undesirable methods are used, even indirectly.</p>



<a name="235751392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235751392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235751392">(Apr 22 2021 at 21:29)</a>:</h4>
<p><span class="user-mention" data-user-id="330154">@The 8472</span> Hmm that is different. To me the annoyance isn't the shear number of CFGs, but that it takes multiple builds to catch whether they are all correct -- hence people talking about more CI failures for things that were working locally in the default configuration. With the portability lint, one effectively does the first few compilation stages simultaneously, which makes any CFG issue very easy to catch with whatever dev env is in use.</p>



<a name="235753335"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235753335" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235753335">(Apr 22 2021 at 21:45)</a>:</h4>
<p>FWIW we can (and should) improve the contribution story around 'wrong' cfg's annotated; I think the lint may be the 'ideal' but is by no means necessary; we can hard code into x.py some logic that would make it always run cargo check for the various configs (perhaps even in the background).</p>



<a name="235753778"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235753778" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235753778">(Apr 22 2021 at 21:48)</a>:</h4>
<p>Doesn't work for target configs at least, you suggested that recently.</p>
<div class="codehilite"><pre><span></span><code>$ ./x.py check --target x86_64-pc-windows-msvc
Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
thread &#39;main&#39; panicked at &#39;
cmake does not support Visual Studio generators.
</code></pre></div>
<p>But it could for this kind of config</p>



<a name="235758662"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235758662" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235758662">(Apr 22 2021 at 22:33)</a>:</h4>
<p>Well, even there, there's no reason for it not to work it just doesn't right now</p>



<a name="235771633"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/235771633" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#235771633">(Apr 23 2021 at 00:58)</a>:</h4>
<p><span class="user-mention silent" data-user-id="330154">The 8472</span> <a href="#narrow/stream/219381-t-libs/topic/alloc.20non-global-oom.20support/near/235753778">said</a>:</p>
<blockquote>
<p>Doesn't work for target configs at least, you suggested that recently.</p>
<div class="codehilite"><pre><span></span><code>$ ./x.py check --target x86_64-pc-windows-msvc
Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
thread &#39;main&#39; panicked at &#39;
cmake does not support Visual Studio generators.
</code></pre></div>
<p>But it could for this kind of config</p>
</blockquote>
<p>I would expect that particular message to go away if you turn on download-ci-llvm</p>



<a name="236036289"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/alloc%20non-global-oom%20support/near/236036289" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/alloc.20non-global-oom.20support.html#236036289">(Apr 25 2021 at 04:26)</a>:</h4>
<p>I have had enormous pains on e.g. a Linux PC trying to contribute to an project targeting multiple OS (Rustup) because of <code>#[cfg]</code> issues. I managed to improve it by cleanly and clearly segmenting everything out as much as I could, but it is monstrously easy to miss something in <em>adding</em> <code>#[cfg]</code> annotations and I did so constantly. At that point, unless I am missing something here, a badass <code>#[cfg]</code> solver can't help much, and neither can a portability lint, if both the use and def site are missing the attribute. <code>#[cfg]</code> is necessary in many cases, even desirable, but I think it should be viewed as a <em>fragile</em> solution compared to other ones, and one that can add a high burden to contributors and reviewers unless it is on an entire module-by-module basis... that is relatively easy to handle, but amounts to something close to the earlier <code>fallible_alloc</code> crate proposal.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>